Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/api/memories.rs`:
- Around line 195-226: The handler currently calls store.save(&memory) before
creating/storing the embedding, which leaves a memory persisted without an
embedding if embed_one or embedding_table().store fails; either move the
embedding step before persisting (call
embedding_model_arc().embed_one(&memory.content) first, then store.save(&memory)
and embedding_table().store) or, if persisting first is required, add a rollback
on failure (on any error from embed_one or embedding_table().store call
store.delete(&memory.id) or equivalent to remove the partially saved memory),
and keep the existing ensure_fts_index() call after successful storage; update
the code paths around store.save, embedding_model_arc().embed_one,
embedding_table().store, and error handling to implement one of these fixes.

---

Nitpick comments:
In `@interface/src/routes/AgentMemories.tsx`:
- Around line 272-274: The effect calls virtualizer.measure() but the dependency
array only needs to react to changes in memories.length and expandedId;
virtualizer is a stable ref from useVirtualizer and can be removed from the
dependencies to avoid a noisy lint-driven inclusion. Update the useEffect in
AgentMemories.tsx to depend only on [memories.length, expandedId] (or if you
must keep the lint happy, remove virtualizer and add a single-line
eslint-disable comment above the useEffect for react-hooks/exhaustive-deps),
leaving the call to virtualizer.measure() unchanged.
- Around line 177-260: createMutation and updateMutation close over component
state (formData, editingMemory) which is fragile; modify both mutations so their
mutationFn accepts an input argument (e.g., variables) and uses that to call
api.createMemory / api.updateMemory instead of reading formData/editingMemory
from closure, and then change saveMemory to build a plain payload (trimmed
content, memory_type, importance, and for updates include editingMemory.id) and
call createMutation.mutate(payload) or updateMutation.mutate(payload); keep the
same success/error handlers (refreshMemories, setEditorOpen, setFormError, etc.)
unchanged.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/api/memories.rs`:
- Around line 197-200: The handler is awaiting synchronous memory persistence
calls (store.save / store.update / store.forget), which blocks the request path;
change these to fire-and-forget by spawning a background task with tokio::spawn
that owns/clones any needed state (e.g., the Store, memory object,
request.agent_id, embedding data) and performs store.save(...).await inside the
spawned task while logging failures with tracing::warn/error there; ensure the
handler returns immediately after spawning the task. Apply the same pattern for
the other occurrences (store.update, store.forget and any embedding writes
referenced in the file).
- Around line 256-305: The handler updates the Memory record before generating
and storing the new embedding, which can leave search inconsistent if embedding
creation/storage fails; change the flow in the content update branch so you
first generate the new embedding via
memory_search.embedding_model_arc().embed_one(&memory.content).await, then
persist the embedding with memory_search.embedding_table().store(&memory.id,
&memory.content, &embedding).await, and only after successful embedding
persistence call store.update(&memory).await (ensuring memory.updated_at is set
just prior to the final update). Do not call
memory_search.embedding_table().delete(...) before the new embedding is safely
stored; instead delete the old embedding only after the new one is persisted,
and if any embedding persistence step fails revert any in-memory changes (i.e.,
do not call store.update or roll back by restoring the previous Memory in the
store) so the DB and embedding index remain consistent.